This package has outlived its usefulness. We removed it from CI in #261, anticipating full removal of the package in a more appropriately scoped PR.

Note: the `yarn.lock` change is a result of running `yarn install` immediately after all of the other changes in this commit.

Manually verified on 22.12.0 (in case `tree-sitter` et al have issues):

- clean install
- monorepo-wide build
- monorepo-wide test (partial run of flaky `web-forms` e2e tests, accepting that they were already flaky and shouldn’t be otherwise affected by this change)

This change updates tree-sitter and related dependencies, and accounts for the current iteration of churn in various special case details of how a tree-sitter project is supposed to work. On the bright side, it turns out things got a lot simpler this time!

- The structure of the `@getodk/tree-sitter-xpath` package is now much more like the other packages. This is largely because the assumptions made by `tree-sitter-cli` are based around a special `tree-sitter.json` file, rather than overloading `package.json` with tree-sitter specific details.

- We no longer (need to) build for Node. Since all of our downstream packages consume the parser as WASM, we benefit from a simpler and (MUCH) faster build step. Note that this may technically be a breaking change (though I’m not sure that it is, since I’m pretty sure we never published the Node bindings, even when they were built).

- Many of the extraneous build artifacts are no longer produced, either because they’re excluded in `tree-sitter.json` or because we are no longer building for Node at all. This allows us to significantly scale down custom build scripting, as well as tree-sitter specific entries in .gitignore/.gitattributes.

- The `tree-sitter` internal build tooling no longer uses `nan`, which also allows us to remove `nan` and `node-gyp` dependencies, and in so doing eliminates another often-fussy thing to check in post-release dep updates.

…ce package

This makes it much easier to run monorepo-wide commands. (I have made this change locally a zillion times to speed up tasks like this one, and it’s never cause a problem. I don’t know what the future for the `scripts` package should be, I’d prefer it go away eventually! But for now it seems reasonable to just remove it here.)

* The following have been skipped, or held back to a semver-minor update:

- Across all packages: Vite has been updated to the latest (presumably last) 5.x.x release, rather than the semver-major update to 6.x.x. I didin’t even bother trying Vite 6, because Vitest won’t support it until January ([source](https://github.com/vitest-dev/vitest/releases/tag/v3.0.0-beta.1)).

    As with previous dependency updates, I have manually prodded Yarn to use the same version of Vite for Vitest’s transitive dependency. How it’s done (every time, but feels worth documenting):

        1. Update direct `vite` dependencies in each affected `package.json`

        2. `yarn install`

        3. Delete the older entry for `vite` in `yarn.lock` (I always spot check that it’s the same one associated with `vitest`, it is also usually associated with `vite-node`.)

        4. `yarn install` again, to update the lockfile so both `^`-range references point to the same version again. (In theory I could make that change manually and then just run `yarn install` again to verify, but I trust the lockfile generation logic more than my typing skills.)

- `@getodk/web-forms`-specific:
    - Vue has been pinned to 3.3.4, consistent with the current version used by Central. (Periodic reminder that we cannot update this until Central does; also we should consider what this means for other potential Vue-based integrations!)
    - PrimeVue &co have not been updated, pending updates to this package coinciding with those upgrades